前言：如何判斷某個檔案是不是主流程？什麼情況適合快速補讀？

上一篇我們完成了管理者後台的整體總結，也把 App 的核心運作流程完整走過了一遍。

在藉由 Hermes Agent 協助重新梳理專案架構時，我注意到 ClassroomScheduleViewModel.kt 與 ClassroomScheduleViewModelFactory.kt 這兩份檔案在先前的功能解析中完全沒被提及。深入追查後才發現：在現有的核心流程中，根本沒有任何 Activity 真正調用它們。

面對這類「看似功能完整、但實際上沒有畫面使用」的檔案，我們該如何快速釐清它的定位？又該如何在不浪費時間逐行精讀的前提下「快速補讀」？今天我們會來探討這問題。

ClassroomScheduleViewModel.kt / ClassroomScheduleViewModelFactory 負責什麼

ClassroomScheduleViewModel ：是課表資料的通用型 ViewModel，提供查空教室、查單一教室詳細資料、批次新增課表資料。

ClassroomScheduleViewModelFactory：建立 ClassroomScheduleViewModel，並把 ClassroomScheduleRepository 傳進去。

為什麼不用深讀？這份檔案與主流程的四大功能重疊

1. 查空教室：核心查詢早已移交專用頁面

• 重疊現象：檔案中的 queryEmptyRooms() 試圖處理空教室的過濾與查詢。
• 現有主流程替代：前台的查詢功能早已由 QueryResultViewModel 搭配 Repository 的查詢機制全權接管，這裡的方法已不再被任何畫面調用。

2. 查單一教室：查詢邏輯分散至各管理頁

• 重疊現象：檔案中定義了 getDetails(roomId) 用來抓取特定教室的課表與屬性。
• 現有主流程替代：包含「一般教室詳情（RoomDetailViewModel）」、「教室細項設定（ClassroomManageViewModel）」以及「完整每週課表（ClassroomScheduleDetailViewModel）」，各頁面都已有自己獨立且更精準的查詢資料流。

3. 資料新增：已有 CSV 初始化與獨立新增介面

• 重疊現象：檔案裡殘留的 insertSchedules() 批次寫入方法。
• 現有主流程替代：專案的資料來源在啟動時直接由 AppDatabase 解析 CSV 預載完成；而後台管理者的手動新增，也已完全由 AllClassroomsViewModel 的專屬新增流程處理。

4. Factory 樣板：標準的依賴注入模式

• 重疊現象：ClassroomScheduleViewModelFactory 只是負責把 Repository 實例餵給 ViewModel。
• 現有主流程替代：它的寫法與整個專案其他所有 Factory 採用完全相同的樣板模式，沒有特殊的客製邏輯，因此在理解專案架構時無需重複精讀。

如何判斷是否被主要流程使用

目前搜尋結果顯示，沒有看到主要 Activity 直接使用：

ClassroomScheduleViewModelFactory(...)

也就是說，它目前沒有接在我們已經整理過的主流程上。

實際主線使用的是更專門的 ViewModel，例如：

• QueryResultViewModel：查詢空教室頁。
• RoomDetailViewModel：一般使用者教室詳細頁。
• LessonManageViewModel：課表管理頁。
• ClassroomManageViewModel：教室類型設定頁。
• ClassroomScheduleDetailViewModel：管理者完整課表頁。

Hermes Agent 如何協助我補讀

在 Day 2 | AI Agent 不是幫我代寫，而是逼我看懂自己的專案
時有提到和 Hermes Agent 的角色會是：透過問答的方式，能更加深我對專案的印象。

不過，既然這兩個檔案沒有接入目前的主流程，逐行精讀對理解 RoomRush 幫助並不大。因此，我改請 Hermes Agent 採取「摘要式補讀」策略：直接抓出它的功能清單，並比對它與現有頁面的重疊之處。

這種方式讓我不需要耗費時間去讀重複的樣板程式碼，就能迅速達成「知道它為何存在、明白為何不用」的理解目標，有效兼顧了專案總覽的完整度與閱讀效率。

小結

讀專案不一定每個檔案都要用同樣深度處理。這次補看的 ClassroomScheduleViewModel 和 Factory，就是一個適合輕量盤點的例子。它提供查空教室、查單一教室、批次新增課表資料等方法，但目前沒有看到主要 Activity 直接使用它。

這讓我學到一個專案閱讀上的重點：
有些程式碼可能是早期版本留下來的，也可能和後來的專用 ViewModel 功能重疊。它們不一定是錯誤，但會增加閱讀成本。比起花很多時間逐行深讀，更有效的方式是先確認它是否接在主流程上、是否被引用、和哪些檔案重疊，再決定要不要深入。

這也可以成為後續技術債清單的一項：檢查是否存在未使用或功能重疊的 ViewModel，並評估是否刪除、合併，或統一資料查詢邏輯。

下一篇預告：重讀 27 天後，我畫出了 RoomRush 的專案總地圖

聊完了專案中的歷史遺留程式碼後，我們的空教室查詢系統其實就已經到了尾聲。

我們由淺入深，依序拆解了「使用者查詢流程」、「資料來源主線」、「管理者功能線」後，下一篇我們要將所有碎片化的知識點收斂為一體－－ 為 RoomRush 繪製完整的專案流程總地圖，從宏觀視角重新審視這款 App 的架構全貌與產品核心價值。